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Abstract 

We  explore  the  idea  of  faking  a  rational  design  process, 
a  la  Parnas  and  Clements  [7],  by  the  application  of  the  ex¬ 
tended  SCR  Method  of  Heitmeyer  and  Bharadwaj.  We  ar¬ 
gue  that  the  formal  artefacts  created  as  a  result  serve  as 
the  basis  for  determining  the  work  products  associated  with 
each  step  of  the  process,  and  whose  quality  assessment  is 
aided  by  the  application  of  tools  in  the  SCR  Toolset.  Fur¬ 
ther,  since  the  products  associated  with  each  step  have  a 
consistent  formal  denotation,  the  approach  opens  the  possi¬ 
bility  of  significantly  automating  many  process  steps. 

1.  Introduction 

The  term  “Rational  Design  Process”  was  introduced  by 
Parnas  and  Clements  in  [7]  to  define  an  ideal  process  in 
which  programs  are  derived  from  the  requirements  in  the 
same  way  that  theorems  are  derived  from  axioms  in  a  proof. 
However,  they  argue,  it  is  impossible  to  find  a  process  in 
practice  that  designs  software  in  a  perfectly  rational  way, 
and  therefore  suggest  that  we  fake  such  a  process,  i.e.,  we 
present  our  system  and  its  associated  documents  to  others 
as  if  we  had  followed  this  idealized  design  process.  They 
justify  the  need  for  this  pretense  by  arguing  that:  (a)  An 
understanding  of  the  ideal  process  provides  designers  guid¬ 
ance  on  how  to  proceed,  (b)  People  will  get  closer  to  a 
rational  design  if  they  try  to  follow  the  process,  (c)  It  is  a 
reasonable  basis  for  specifying  a  “standard  process”,  fd)  It 
is  easier  to  provide  metrics  on  a  project  if  it  is  compared 
with  the  ideal  process,  (e)  Attempting  to  follow  a  standard 
process  eases  a  project’s  review.  Finally,  they  argue  that 
management  of  such  a  process  that  is  described  in  terms  of 
work  products  becomes  easier  since  we  know  which  work 
products  are  due,  and  what  criteria  they  must  satisfy. 

In  [1,  3]  Heitmeyer  and  Bharadwaj  outline  a  four 
step  process  for  the  behavioral  specification  of  software¬ 
intensive  embedded  systems.  Each  step  in  the  process  re¬ 


sults  in  the  construction  of  a  formal  artefact  that  is  amenable 
to  formal  inspection,  validation,  verification,  and  consis¬ 
tency  checking.  In  this  paper,  our  tentative  proposal  is 
that  we  additionally  consider  two  architectural  specification 
documents.  Although  these  artefacts  may  differ  somewhat 
from  the  products  considered  by  Parnas  and  Clements  in 
[7],  we  argue  that  the  SCR  notation,  the  SCR  formal  model 
[5],  and  tools  associated  with  the  SCR  method  [2,  4]  can 
serve  as  the  basis  for  the  construction  of  the  products  of  a 
rational  design  process.  The  benefit  of  this  approach  is  that 
many  of  the  desirable  properties  of  the  products  considered 
in  [7]  are  natural  outcomes  of  the  application  of  the  SCR 
method  and  tools.  We  argue  therefore  that  adopting  the  SCR 
method  and  using  the  SCR  tools  leads  us  closer  to  the  ide¬ 
alized  design  process  because  of  the  separation  of  concerns 
in  each  step  of  the  process  and  precise  formal  criteria  upon 
which  the  artefacts,  constructed  as  a  result  of  each  step,  are 
evaluated.  What  remains  to  be  done  is  to  provide  a  set  of 
guidelines  suitable  for  use  by  developers  and  precise  doc¬ 
umentation  of  the  “SCR  Rational  Process”  itself,  along  the 
lines  suggested  in  [7], 

2  Behavioral  Specifications 

Behavioral  specifications  of  the  system  and  software  are 
constructed  using  the  notation  of  SCR.  The  four  steps  of  the 
extended  SCR  method  of  [1,  3]  are  shown  in  Figure  1. 

The  first  step  creates  the  System  Requirements  Specifica¬ 
tion  (SRS),  which  describes  the  required  external  behavior 
of  the  system  in  terms  of  the  quantities  in  the  environment 
that  the  system  monitors  and  controls.  The  structure  of  the 
SRS  is  dictated  by  the  structure  of  the  system  architecture 
(see  next  section)  -  the  SRS  may  be  composed  of  modules, 
each  corresponding  to  an  element  in  the  system  architec¬ 
tural  specification.  The  second  step  creates  the  System  De¬ 
sign  Specification  (SDS),  which  identifies  the  input  and  out¬ 
put  variables  associated  with  the  sensors  and  actuators  on 
each  hardware  platform  of  the  system.  The  third  step  cre¬ 
ates  the  Software  Requirements  Specification  (SoRS)  by  ex- 
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Figure  1.  Relationship  between  the  artefacts 
of  the  SCR  method. 


tending  each  SRS  module  with  two  additional  specifications 
that  (1)  relates  the  input  devices  to  the  monitored  quantities 
of  the  system  and  (2)  the  controlled  quantities  of  the  system 
to  the  output  devices.  The  fourth  step  extends  the  SRS  with 
behavior  to  handle  hardware  malfunctions  such  as  sensor 
and  actuator  failures,  and  timing  and  accuracy  constraints. 


and  the  major  algorithms  used  in  the  implementation.  It  is 
important  to  note  that,  with  certain  restrictions,  it  is  possi¬ 
ble  to  generate  efficient  and  verified  code  directly  from  the 
software  requirements  specification.  This  has  remained  a 
search  for  the  philosopher’s  stone  with  other  specification 
notations  such  as  UML.  However,  with  SCR  specifications, 
it  is  possible  to  automate  substantial  portions  of  the  code 
creation  process  as  demonstrated  by  Heitmeyer  et  al.  [6], 

5  Conclusions 

We  demonstrate  that  the  SCR  method  is  well  suited  for 
faking  the  ideal  development  process.  In  addition  to  con¬ 
ventional  reviews  and  inspection,  specifications  in  SCR  are 
amenable  to  mechanical  checking  and  verification,  thereby 
considerably  easing  the  burden  on  the  designers  and  review¬ 
ers.  Adopting  SCR  also  promotes  seamless  transition  be¬ 
tween  the  process  steps,  since  all  the  artefacts  have  a  con¬ 
sistent  underlying  formal  semantics,  based  on  the  SCR  for¬ 
mal  model  [5].  Finally,  the  behavioral  descriptions  in  SCR 
have  a  precise,  mathematical  semantics  and  therefore  lend 
themselves  well  to  the  automatic  generation  of  substantial 
portions  of  the  implementation.  Parnas  and  Clements  say  in 
conclusion  in  [7]  that  being  a  rational  designer  is  very  hard, 
and  that  even  faking  that  process  can  be  difficult.  We  posit 
that,  for  the  designer,  adopting  the  SCR  method  and  using 
the  SCR  tools  will  considerably  ease  this  process. 


3  Architectural  Specifications 

In  this  paper,  we  propose  that  each  behavioral  specifi¬ 
cation  should  be  accompanied  by  an  associated  architec¬ 
tural  specification.  The  notation  we  propose  for  archi¬ 
tectural  specifications  is  similar  to  wiring  diagrams  used 
by  Electrical  Engineers  to  specify  component  interconnec¬ 
tions.  The  System  Architectural  Specification  documents 
the  proposed  physical  configuration  of  the  computer  hard¬ 
ware.  The  Software  Architectural  Specification  documents 
the  internal  structure  of  the  software  on  each  computing 
platform.  If  the  underlying  software  is  designed  using  an 
object-oriented  method,  then  a  class  diagram  should  prob¬ 
ably  be  included  as  an  adjunct  to  the  software  architectural 
specification.  The  class  diagram  serves  as  a  surrogate  for 
documenting  the  module  structure,  module  interfaces,  and 
the  uses  hierarchy  as  proposed  in  [7]. 

4  Software  Design  and  Implementation 

The  software  design  document  records  the  major  design 
decisions  of  each  module  (or  class)  which  is  intended  to 
allow  a  quick  review  of  the  design  before  coding  begins 
[7].  This  includes  descriptions  of  the  internal  data  structures 
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